fix(sandbox): add DNS forwarder for sandbox network namespace#1
Open
nic-nvidia wants to merge 1 commit intomainfrom
Open
fix(sandbox): add DNS forwarder for sandbox network namespace#1nic-nvidia wants to merge 1 commit intomainfrom
nic-nvidia wants to merge 1 commit intomainfrom
Conversation
The sandbox runs in an isolated network namespace where the only route is to the host side of a veth pair (10.200.0.1). The pod resolv.conf points to CoreDNS (10.43.0.10), which is unreachable from the sandbox netns because kube-proxy iptables rules only exist in the pod original netns. Applications that honor HTTP_PROXY route through the CONNECT proxy (which resolves DNS on the host side), but WebSocket clients and other tools that resolve DNS directly fail with getaddrinfo EAI_AGAIN. This adds a lightweight UDP DNS forwarder that: - Listens on the host veth IP port 53 (reachable from sandbox) - Forwards queries to the pod original upstream DNS server - Overwrites /etc/resolv.conf to point at the forwarder The proxy still enforces network policy on TCP connections. DNS resolution alone does not grant network access. Tested with OpenClaw sandbox: Discord WebSocket gateway now connects successfully where it previously failed with EAI_AGAIN. Signed-off-by: Nic Borensztein <nborensztein@nvidia.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Applications inside sandboxes that do not honor
HTTP_PROXYcannot resolve DNS. This breaks WebSocket connections — including Discord and WhatsApp integrations in OpenClaw sandboxes.The sandbox's only network path is through the HTTP CONNECT proxy, which works for tools like
curl,fetch, andgitthat readHTTP_PROXY. But WebSocket libraries (Discord.js, Baileys) resolve DNS directly and fail with:This PR adds a lightweight DNS forwarder on the host side of the veth pair so all DNS resolution works, regardless of whether the app uses
HTTP_PROXY. The proxy still enforces network policy on TCP connections — DNS resolution alone does not grant access.Reproduction
Changes
dns_forwarder.rs: UDP forwarder that listens on<host_veth_ip>:53, relays queries to the pod's upstream DNS, and rewrites/etc/resolv.confto point at itselflib.rs: starts the forwarder during sandbox init (non-fatal — logs a warning and continues if it fails)tokio::net::UdpSocketalready in the tree)Why DNS is broken
The sandbox runs in an isolated network namespace where the only route is
10.200.0.1(host side of the veth pair). The pod's/etc/resolv.confpoints to CoreDNS at10.43.0.10, but the kube-proxy iptables DNAT rules that make that address work only exist in the pod's original netns — not in the sandbox netns. Any direct DNS query times out.Testing
nslookup/getent hostsresolve inside sandboxEAI_AGAIN)mise run ci(no access to full CI environment)Checklist